Add leaves for common org-defined TLVs to LLDP neighbor state by yogeshg-arista · Pull Request #1478 · openconfig/public

yogeshg-arista · 2026-04-22T09:51:32Z

Resolves Issue #1471

(M) release/models/lldp/openconfig-lldp.yang

Change Scope

Add the following new read-only leaves under /lldp/interfaces/interface/neighbors/neighbor/state for widely implemented, standards-based LLDP TLVs:
- med-inventory-serial-number (string) — LLDP-MED Inventory Serial Number TLV (OUI 00-12-BB, subtype 8)
- port-vlan-id (uint16 { range 0..4094 }) — IEEE 802.1 Port VLAN ID TLV (OUI 00-80-C2, subtype 1)
- link-aggregation (container) — IEEE 802.3 Link Aggregation TLV (OUI 00-12-0F, subtype 3), containing:
- - capable (boolean)
- - enabled (boolean)
- - port-id (uint32)
- max-frame-size (uint16) — IEEE 802.3 Maximum Frame Size (OUI 00-12-0F, subtype 4)
These TLVs are defined in IEEE 802.1, IEEE 802.3, and ANSI/TIA-1057 and are broadly supported across network platforms. They are essential for network automation use cases including inventory management.
This change is backward compatible (minor version bump 1.1.0 → 1.2.0).

Platform Implementations

Arista: These TLVs are supported in EOS CLI via show lldp neighbors detail. See LLDP EOS User Manual and sample CLI output below.

Interface Ethernet36/1 detected 1 LLDP neighbors:

  Neighbor 3838.a6a5.5d04/"Ethernet36/1", age 7 seconds
  - IEEE802.1 Port VLAN ID: 0
  - IEEE802.3 Link Aggregation
    Link Aggregation Status: Capable, Enabled (0x03)
    Port ID                : 1000002
  - IEEE802.3 Maximum Frame Size: 10240 bytes
  - LLDP-MED Inventory Serial Number TLV: "FGN234408B7"

Tree View

 module: openconfig-lldp 
 path: /lldp/interfaces/interface/neighbors/neighbor/state
   +--ro state
      +--ro system-name?                   string
      +--ro system-description?            string
      +--ro chassis-id?                    string
      +--ro chassis-id-type?               oc-lldp-types:chassis-id-type
      +--ro management-interface?          oc-if:interface-id
      +--ro id?                            string
      +--ro age?                           uint64
      +--ro last-update?                   int64
      +--ro ttl?                           uint16
      +--ro port-id?                       string
      +--ro port-id-type?                  oc-lldp-types:port-id-type
      +--ro port-description?              string
      x--ro management-address?            string
      x--ro management-address-type?       string
+     +--ro med-inventory-serial-number?   string
+     +--ro port-vlan-id?                  uint16
+     +--ro link-aggregation-capable?      boolean
+     +--ro link-aggregation-enabled?      boolean
+     +--ro link-aggregation-port-id?      uint32
+     +--ro max-frame-size?                uint16

gemini-code-assist

Code Review

This pull request updates the LLDP model to version 1.1.0, introducing new neighbor state leaves for LLDP-MED inventory serial numbers, IEEE 802.1 port VLAN IDs, and IEEE 802.3 link aggregation and maximum frame size. The review feedback highlights that the port-vlan-id should be adjusted to allow a value of 0 for non-VLAN-aware ports and suggests replacing the uint8 bitfield for link aggregation with explicit boolean leaves to follow OpenConfig conventions for telemetry usability.

…nto booleans - Replace oc-vlan-types:vlan-id with uint16 range 0..4094 to allow PVID value 0 (port not VLAN-aware per IEEE 802.1Q) - Remove unused openconfig-vlan-types import - Replace link-aggregation-status uint8 bitfield with two explicit boolean leaves: link-aggregation-capable and link-aggregation-enabled

dplore · 2026-05-05T16:14:23Z

/gcbrun

OpenConfigBot · 2026-05-05T16:16:12Z

No major YANG version changes in commit 69ac85c

rgwilton · 2026-05-07T13:49:16Z

Re:

+     +--ro med-inventory-serial-number?   string
+     +--ro port-vlan-id?                  uint16
+     +--ro link-aggregation-capable?      boolean
+     +--ro link-aggregation-enabled?      boolean
+     +--ro link-aggregation-port-id?      uint32
+     +--ro max-frame-size?                uint16

I would suggest putting the three link-aggregation fields into a link-aggregation container, and then naming the fields capable, enabled, port-id.

ElodinLaarz · 2026-05-07T15:26:27Z

Reviewed at the OC Community Meeting May 7th, 2026:

Could we get another vendor to review / comment if they already implement this behavior?

ElodinLaarz · 2026-05-07T15:26:39Z

/gcbrun

1. Group link-aggregation-capable, link-aggregation-enabled, and link-aggregation-port-id into a link-aggregation container with shortened leaf names (capable, enabled, port-id) - Fix trailing whitespace and reference indentation in revision block

yogeshg-arista · 2026-05-12T15:17:34Z

Re:
+     +--ro med-inventory-serial-number?   string
+     +--ro port-vlan-id?                  uint16
+     +--ro link-aggregation-capable?      boolean
+     +--ro link-aggregation-enabled?      boolean
+     +--ro link-aggregation-port-id?      uint32
+     +--ro max-frame-size?                uint16
I would suggest putting the three link-aggregation fields into a link-aggregation container, and then naming the fields capable, enabled, port-id.

I have created the container link-aggregation with leaves capable, enabled and port-id.

dplore · 2026-05-26T16:55:10Z

Re:
+     +--ro med-inventory-serial-number?   string
+     +--ro port-vlan-id?                  uint16
+     +--ro link-aggregation-capable?      boolean
+     +--ro link-aggregation-enabled?      boolean
+     +--ro link-aggregation-port-id?      uint32
+     +--ro max-frame-size?                uint16
I would suggest putting the three link-aggregation fields into a link-aggregation container, and then naming the fields capable, enabled, port-id.

Hi, @rgwilton does Cisco implement support for this data? Can you provide a link for the benefit of this PR?

dplore · 2026-05-26T16:55:16Z

/gcbrun

navaneethyv · 2026-06-02T16:40:57Z

Hello @rgwilton , bumping it up.

@yogeshg-arista can you please help getting the reference implementations from other vendors, we will be able to merge this PR in once we have that.

rgwilton · 2026-06-04T15:36:35Z

@dplore, I think that we support some of these TLVs (e.g., IEEE 802.1 Port VLAN ID TLV), but not the other TLVs that are being proposed, as least in IOS XR.

earies

Suggest adding reference statements to each leaf proposed here to clarify which governing specs (IEEE/ANSI), OUIs + sections each correspond to

earies · 2026-06-16T22:39:09Z

+    }
+
+    leaf port-vlan-id {
+      type uint16 {


I'd say we're at the point where there should be a proper reusable typedef for this - the closest current one sits in openconfig-vlan-types but restricts to 1..4094 - maybe something directly in openconfig-types or adjustment within that model is warranted

Thanks for the suggestion @earies. We see two options here:

Option 1: New typedef (e.g. vlan-id-or-none) in openconfig-vlan-types

A new typedef with range 0..4094 that explicitly documents the semantics of 0 (the system either does not know the PVID or does not support Port-based VLAN operation). This keeps the existing vlan-id (range 1..4094) untouched, so no risk to current consumers. The downside is introducing a second VLAN ID typedef that is very similar to the existing one.

Option 2: Widen existing vlan-id typedef from 1..4094 to 0..4094

One typedef covers both cases. But this changes the contract for all existing users of vlan-id across OpenConfig models. Config leaves that use this typedef would suddenly accept 0, which may not be meaningful in those contexts, and implementations might mishandle the value 0.

Given the risks of Option 2, we lean toward Option 1 but would appreciate the community's input. Also open to keeping the inline uint16 { range "0..4094"; } as-is if a new typedef isn't warranted for a single use.

@dplore @earies @rgwilton and the community, please let us know your thoughts on this.

earies · 2026-06-16T22:57:51Z

@yogeshg-arista can you please help getting the reference implementations from other vendors

From JUNOS/EVO perspective, these are all supportable

1. Add references for common org-defined TLVs in LLDP neighbor state 2. Do not create a new container for link-aggregation in LLDP neighbor state

yogeshg-arista · 2026-06-17T12:08:37Z

Suggest adding reference statements to each leaf proposed here to clarify which governing specs (IEEE/ANSI), OUIs + sections each correspond to

I have added references for all the new leaves.

yogeshg-arista · 2026-06-17T12:39:00Z

Re:
+     +--ro med-inventory-serial-number?   string
+     +--ro port-vlan-id?                  uint16
+     +--ro link-aggregation-capable?      boolean
+     +--ro link-aggregation-enabled?      boolean
+     +--ro link-aggregation-port-id?      uint32
+     +--ro max-frame-size?                uint16
I would suggest putting the three link-aggregation fields into a link-aggregation container, and then naming the fields capable, enabled, port-id.
I have created the container link-aggregation with leaves capable, enabled and port-id.

As per the discussion in the community meeting dated June 4, 2026, it was discussed that a new container here is against the common OC state pattern.

Reverting back to the original change with separate leaves link-aggregation-capable, link-aggregation-enabled and link-aggregation-port-id directly in the neighbor state container.

earies · 2026-06-17T19:16:27Z

Re:
+     +--ro med-inventory-serial-number?   string
+     +--ro port-vlan-id?                  uint16
+     +--ro link-aggregation-capable?      boolean
+     +--ro link-aggregation-enabled?      boolean
+     +--ro link-aggregation-port-id?      uint32
+     +--ro max-frame-size?                uint16
I would suggest putting the three link-aggregation fields into a link-aggregation container, and then naming the fields capable, enabled, port-id.
I have created the container link-aggregation with leaves capable, enabled and port-id.
As per the discussion in the community meeting dated June 4, 2026, it was discussed that a new container here is against the common OC state pattern.

Reverting back to the original change with separate leaves link-aggregation-capable, link-aggregation-enabled and link-aggregation-port-id directly in the neighbor state container.

I assume this is just in relation to nesting another container as a child of ./state - in that case, categorizing appropriately as a sibling should suffice?

yogeshg-arista added 4 commits April 14, 2026 10:19

Add leaves for common org defined TLVs to LLDP model

1f2a84f

Add leaves for common org defined TLVs to LLDP model

2053cff

Merge branch 'master' of github.com:yogeshg-arista/public

db884d6

Merge branch 'openconfig:master' into master

1e33506

github-project-automation Bot added this to OC Operator Review Apr 22, 2026

gemini-code-assist Bot reviewed Apr 22, 2026

View reviewed changes

Comment thread release/models/lldp/openconfig-lldp.yang

Comment thread release/models/lldp/openconfig-lldp.yang Outdated

yogeshg-arista marked this pull request as ready for review April 22, 2026 09:56

yogeshg-arista requested a review from a team as a code owner April 22, 2026 09:56

yogeshg-arista and others added 3 commits April 22, 2026 03:18

Remove extra newline.

ebc906f

Merge branch 'master' into master

390598a

dplore moved this to Ready to discuss in OC Operator Review May 5, 2026

OpenConfigBot added the non-breaking label May 5, 2026

Merge branch 'master' into master

cdbef70

yogeshg-arista closed this May 7, 2026

yogeshg-arista reopened this May 7, 2026

earies reviewed Jun 16, 2026

View reviewed changes

Address comments in PR 1478

046af94

1. Add references for common org-defined TLVs in LLDP neighbor state 2. Do not create a new container for link-aggregation in LLDP neighbor state

Conversation

yogeshg-arista commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Change Scope

Platform Implementations

Tree View

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

dplore commented May 5, 2026

Uh oh!

OpenConfigBot commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rgwilton commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ElodinLaarz commented May 7, 2026

Uh oh!

ElodinLaarz commented May 7, 2026

Uh oh!

yogeshg-arista commented May 12, 2026

Uh oh!

dplore commented May 26, 2026

Uh oh!

dplore commented May 26, 2026

Uh oh!

navaneethyv commented Jun 2, 2026

Uh oh!

rgwilton commented Jun 4, 2026

Uh oh!

earies left a comment

Choose a reason for hiding this comment

Uh oh!

earies Jun 16, 2026

Choose a reason for hiding this comment

Uh oh!

yogeshg-arista Jun 17, 2026

Choose a reason for hiding this comment

Uh oh!

earies commented Jun 16, 2026

Uh oh!

yogeshg-arista commented Jun 17, 2026

Uh oh!

yogeshg-arista commented Jun 17, 2026

Uh oh!

earies commented Jun 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

yogeshg-arista commented Apr 22, 2026 •

edited

Loading

OpenConfigBot commented May 5, 2026 •

edited

Loading

rgwilton commented May 7, 2026 •

edited

Loading